Répertoire (directory or folder)
CLI: Command Line Interface
J.-M. Bruel
Un programme de gestion de version de code source (VCS — Version Control System)
Gratuit et open source
Distribué (contrairement à Subversion par exemple)
Créé à Linus Torvalds (2005)
Répertoire (directory or folder)
CLI: Command Line Interface
Dépôt (repository)
GitHub.com (ou GitLab.com ou gitlab.iut-blagnac.fr)
On initialise certaine variables (une fois pour toute en général) :
$ git config --global user.name "JM Bruel"
$ git config --global user.email jbruel@gmail.com
$ git config --global alias.co checkoutCes informations sont stockées dans le fichier Voici un extrait du mien : Ce qui donne : |
On démarre la gestion de version :
$ git initGénération d’un répertoire |
On ajoute les fichiers courants au dépôt :
$ git add .
|
|
On peut visualiser les actions en vérifiant l'état courant du dépôt :
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Generalites.txt
# deleted: S3/128056_56.d
...Pour entériner les changements :
$ git commit -m "First draft"
[master (root-commit) 4f40f5d] First draft
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 titi.txt
create mode 100644 toto.txt
|
Exemple de scénario type (suppression exceptionnelle et rattrapage) :
$ rm titi.txt
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: titi.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout -f
$ ls titi.txt
titi.txtAprès avoir créé un dépôt distant, il n’y a plus qu’à associer ce dépôt distant avec le notre.
$ git remote add origin git@github.com:jmbruel/first_app.git (1)
$ git push -u origin master (2)
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 225 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:jmbruel/first_app.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.| 1 | Il est possible d’avoir plusieurs dépôts distants, celui-ci sera référencé par origin. |
| 2 | L’option -u origin master permet d’associer une fois pour toute les git push suivants au fait
de "pousser" sur la branche master du dépôt origin (comme l’indique la dernière ligne). |
En cas d’édition et de commit local :
$ git checkout
Your branch is ahead of 'origin/master' by 1 commit.Après modification :
$ git status
# On branch testModifTiti
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: titi.txt
#
no changes added to commit (use "git add" and/or "git commit -a")On "sauvegarde" les changements :
$ git commit -am "modif de titi"
[testModifTiti 4515b5d] modif de titi
1 files changed, 7 insertions(+), 0 deletions(-)
|
On peut "zapper" d’une branche à l’autre à volonté :
$ ll titi*
-rw-rw-r-- 1 bruel staff 331 12 nov 12:39 titi.txt
$ git co master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
$ ll titi*
-rw-rw-r-- 1 bruel staff 0 12 nov 12:40 titi.txtMaintenant que la branche a été développée (testée, etc.) on peut l’intégrer à la branche principale :
$ git co master
Switched to branch 'master'
$ git merge testModifTiti
Merge made by recursive.
titi.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
|
Maintenant que notre dépôt est satisfaisant, on peut le synchroniser avec le dépôt distant :
$ git push
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 977 bytes, done.
Total 9 (delta 2), reused 0 (delta 0)
To git@github.com:jmbruel/first_app.git
6103463..3aae48a master -> master$ git checkout -b develop origin/develop
$ ... (1)
$ git checkout master
$ git merge --no-ff develop (2)
$ git push origin master (3)| 1 | Vérifiez ce qui va être intégré |
| 2 | On merge localement pour gérer les problèmes |
| 3 | On pousse sur master |
Si vous devez partir d’un dépôt existant :
$ git clone git@github.com:jmbruel/first_app.git
|
Même après un git add ! |
Voici une illustration de l’utilisation des branches (tirée de git-scm).
On part d’une situation type :
On modifie et on commit :
$ edit ...
$ git commit -m "blabla iss53"On commence à diverger de master |
On revient à la branche maître pour tester une autre solution :
$ git checkout master
$ git checkout -b hotfix
$ edit ...
$ git commit -m "blabla hotfix"On continue à travailler sur la branche iss53 :
$ git branch -d hotfix (1)
$ git checkout iss53
$ edit ...
$ git commit -m "blabla iss53"| 1 | Destruction de la branche devenue redondante avec master. |
On retravaille sur iss53 |
On intègre cette branche :
$ git checkout master
$ git merge iss53| Merge sans fast-forward |
| Situation finale |
|
Ce qu’il ne faut pas versionner :
les exécutables
les zip dont le contenu change sans arrêt
les images générées
tous les binaires en général!
En on peut taguer des branches et c’est ce mécanisme qui
permet de gérer simplement les releases.
Dans l’exemple ci-dessous on tague le commit ebb0a7 avec le tag v1.0.
$ git tag -a v1.0 ebb0a7 -m "Release 1.0 as required by client"
$ git tag
v1.0
$ git push origin v1.0| ne pas oublier de "pousser" le tag. |
On peut voir les détails d’un commit tagué :
$ git show v1.0
tag v1.0
Tagger: Jean-Michel Bruel <jbruel@gmail.com>
Date: Fri Sep 16 14:27:20 2016 +0200
Release 1.0 as required by client
commit 47da474098d95f8ef5c3ca838be8b87d7a7ed729
Author: Jean-Michel Bruel <jbruel@gmail.com>
Date: Fri Sep 16 12:38:20 2016 +0200On peut aussi taguer a posteriori :
$ git tag -a v1.2 9fceb02 (1)| 1 | ajoute le tag v1.2 au commit dont le [SHA-1] commence par 9fceb02 |
Par défaut les tags ne sont pas poussés sur le dépôt distant. |
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend$ git add *.*
$ git reset *.class| Aucun danger |
$ working on some file README.adoc ...
$ git checkout -- README.adoc| Danger! |
$ git statusPour faire simple, je vous conseille une gestion qui marche bien pour les petites équipes, tiré de l’excellent livre Pro Git :
Deux branches seulement: master et develop.
$ git branch
* develop (1)
master (2)| 1 | develop est la branche de travail qui contient la dernière version des codages en cours. |
| 2 | master est toujours stable et sert au déploiement |
On fork develop pour traiter un bug ou une feature.
On merge dans develop
On détruit la branche devenue inutile
Ce qui donne le flot suivant dès que vous devez faire une amélioration (corriger un bug ou ajouter une fonctionnalités) :
Créer une branche (e.g., fix-451)
Travailler sur cette branche
Merger cette branche dans develop
Rejouer les tests
Régler les conflits éventuels
Quand tout fonctionne ⇒ [pull-request]
On peut livrer à partir de master
mergemergemergemergemerge vs. rebasegit merge JMB:
git rebase JMB:
$ git checkout master
$ git merge other_branch
Auto-merging toto.txt
CONFLICT (content): Merge conflict in toto.txt
Automatic merge failed; fix conflicts and then commit the result.
$ more toto.txt
<<<<<<< HEAD (1)
Salut monde
======= (2)
hello world!
>>>>>>> other_branch (3)
$ vi toto.txt (4)
$ git commit (5)git diff
git difftool
Ne pas simplement cloner, car soucis de synchro plus tard.
Faire :
$ git submodule add https://github.com/chaconinc/DbConnector
Cloning into 'DbConnector'...
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 11 (delta 0), reused 11 (delta 0)
Unpacking objects: 100% (11/11), done.
Checking connectivity... done.Vous devez voir apparaître, en plus du répertoire cloné, un fichier .gitmodules (si c’est la 1ère fois). |
Voici un schéma pour résumer la philosophie (tiré de http://osteele.com) :